David Heinemeier Hansson, creator of Ruby on Rails, announced that his company 37signals has stopped writing code by hand and now treats manual coding as an exception—a shift he compares to photography's impact on painting. The move reflects a broader industry transition where AI agents are becoming the primary code writers, raising concerns about software quality and what engineering work actually means.

• DHH declared he's retired from programming after 25 years and now sees himself as a "maker of things" steering AI agents rather than writing code directly. 37signals is shifting to native mobile apps and Rust backends because agents can produce adequate code in these areas, while keeping Ruby on Rails only because its conventions work well with AI.
• Software quality is visibly degrading across the industry. Engineers are shipping untested features, working 12-13 hour days just reviewing AI output without understanding it, and outsourcing all thinking to LLMs. Recent examples include Spotify outages and Uber Eats bugs that suggest zero QA testing.
• This transition is happening faster than predicted—model improvements since November 2025 have made AI coding genuinely viable, not theoretical. Non-engineers at companies like Craft Docs and OpenAI are now using AI agents for customer support, marketing, HR, and finance work, not just engineering.

Software quality comes from consistently fixing small problems and locking in improvements through tests and processes, not from occasional big wins. Most organizations skip this work, which causes quality to erode back to mediocrity.

• Excellence in software requires hundreds of small polishes and bug fixes fitted together consistently, not individual heroic efforts or major features.
• Bug fixes should take priority over new features because without them, software quality inevitably degrades to a 7/10 level—things like tooltips, performance, and edge cases break and stay broken.
• Organizations need processes (tests, code review, shorter feedback loops, high coding standards) that lock in improvements so quality gains don't disappear over time.

Dan Luu argues that while LLMs have improved at code generation, relying on them without human oversight produces broken software. The real problem isn't LLM capability—it's that people declaring "programming is solved" are shipping products that don't work and fooling themselves about quality standards.

• LLMs fail consistently on out-of-distribution problems, nuanced requirements, and tasks with hidden constraints—exactly what real software projects contain. They perform well only on narrow, well-defined tasks.
• When developers outsource thinking to LLMs and walk away, the software has serious bugs: infinite loops, broken functionality, overfitting to tests, and logic errors that code review catches immediately.
• The gap between "works for me" personal projects and shipping commercial products matters. People claiming LLMs solve programming often confuse the former with the latter, or ship low-quality code while ignoring obvious defects.

This piece jokes about relying on “hope” instead of tests or planning in software projects. It pokes fun at developers who ship code and cross their fingers rather than following structured workflows.

• "Hope-Driven Development" is a joke term riffing on Test-Driven Development, but with the tests removed entirely
• The humor targets the common practice of shipping quick hacks (with maybe a stray console log) and just hoping production doesn't break
• It resonates because it mirrors real habits like skipping unit tests, ignoring edge cases, and deploying on faith, especially late in a Friday sprint